N 92-11063 


A Planning Language for Activity Scheduling 


David Zoch, David LaVallee, Stuart Weinstein 

Ford Aerospace 

7375 Executive Place, Suite 1(X) 

Seabrook, MD 20706 



(i. Michael Tong 

Goddard Space Flight Center 
Data Systems Technology Division, Mail Code 522 
Greenbelt, MD 20771 


Abstract 

Mission planning and scheduling of spacecraft 
operations arc becoming more complex at NASA. 
Spacecraft contain increasingly powerful onboard 
computers which may be commanded to a vast number 
of modes and configurations. Automated planning and 
scheduling tools are needed to support the dramatic 
increase in capabilities, system performance, and user 
flexibilities. This paper describes a mission planning 
process; a robust, flexible planning language for 
spacecraft and payload operations; and a software 
scheduling system that generates schedules based on 
the planning language inputs. The mission planning 
process often involves many people and organizations. 
Consequently, a planning language is needed to 
facilitate communication, to provide a standard 
interface, and to represent flexible requirements. The 
software scheduling system interprets the planning 
language and uses the resource, time duration, 
constraint, and alternative plan flexibilities to resolve 
scheduling conflicts. 

1 Background 

NASA performs several types of scheduling. Each type 
requires different approaches and tools. Examples of types 
of scheduling include the following: 

• project scheduling; Tracking the progress of a 
project development team. 

• payload manifesting : Determining the payload 
manifests for Space Shuttle missions. 

• job shop scheduling: Refurbishing four Space 
Shuttles for repeated launches. 
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• activity scheduling: Arranging activities to prcxlucc a 
time line of operations and procedures. 

The concepts, approaches, and systems described in this 
paper apply specifically to activity scheduling, which is a 
part of the mission planning and scheduling process. 

We arc concerned with the planning and scheduling of 
NASA mission operations with respect to spacecraft, Eight 
instruments, space and ground communications networks, 
and NASA customers (science, application, and commercial 
users). In our applications, planning consists of deciding 
which instrument activities, spacecraft activities, and ground 
activities to perform, while scheduling consists of allocating 
resources to the activities and sequencing them onto a time 
line to produce a schedule. Planning is performed by 
mission planners and science users. Scheduling is currently 
performed manually with varying degrees of computer 
assistance but, as wc show here, can become highly 
automated. We focus on the short term time frame from 
four weeks before an activity occurs to the actual real time 
support of an activity. Strategic planning and tactical 
planning involve long-term planning conducted months and 
years in advance and arc outside of our planning process 
except that their products, the mission goals, serve as inputs 
to our applications. 

Activity scheduling includes allocating resources and 
assigning times to spacecraft and instrument activities. If 
resources arc scarce, one must decide which activities cannot 
be scheduled. Temporal constraints between activities 
restrict activity scheduling (c.g.. Activity A must be 
scheduled before Activity B). 

Several techniques arc available for generating conflict- 
free schedules, including hybrid neural nclwork/heurisiic 
approaches as described in [Gaspin, 1989), heuristic 
approaches as described in [Berner, 1989|, and, M the 
problem is sufficiently constrained, mathematical 
programming approaches (linear and nonlinear) as in | Reddy, 
1989]. Techniques for improving an existing schedule 
include a neural network approach as described in |Sponslcr 
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and Johnston, 1990) and a best-first search approach as 
described in (Odubiyi and Zoch, 1989). 

As flexibilities arc added to plans, the scheduling 
procedure becomes more complex. For instance, if specific 
resource requirements, start times, and end times for an 
activity are requested, a scheduling system can respond with 
a yes or no. If flexible resource requirements and general 
temporal requirements arc specified instead of specific 
requirements, the scheduling software must search the 
current schedule for places where temporal requirements and 
resource requirements are met. If nominal resource 
requirements cannot be met, the scheduling system can 
utilize the specified resource flexibilities and try again to 
schedule the activity. For example, instead of specifying a 
request for a 10-minutc communication with TDRS-E 
(Tracking and Data Relay Satellite, East) at 3 p.m. on a 
certain day, a plan might specify that communication with 
either TDRS (East or West) is needed between 2 p.m. and 4 
p.m. 

The Data Systems Technology Division (Code 520) at 
Goddard Space Flight Center has developed a testbed to 
investigate the scheduling process for increasingly complex 
future NASA missions. The testbed includes a mission 
planning and scheduling system called the Request-Oriented 
Scheduling Engine (ROSE), that addresses the activity 
scheduling problem. Spacecraft operation plans are input to 
ROSE in a robust planning language called the Flexible 
Envelope Request Notation (FERN). 

In this paper wc describe (1) the need for increased 
automation in mission planning and scheduling, (2) the 
mission planning and scheduling process, (3) the FERN, and 
(4) the ROSE. 

2 The Need for Automation 

Several factors motivate the need for increased automation. 

I hese factors include the complexity of flight instruments 
and spacecraft, the need to provide increased flexibility to 
users, the need for safety, and the support for complex, 
distributed scheduling architectures. Each factor is discussed 
below. 

2.1 Complexity of Flight Systems 

NASA flight instruments and spacecraft arc physically larger 
and more complex than past space systems. Past space 
systems were relatively simple since there was no way to 
repair onboard hardware failures. Now, the Space Shuttle 
crew can repair and service low-earth orbiting spacecraft. 
Thus, a major obstacle that restrained complexity has been 
removed for many missions. 

Increasingly powerful onboard computers have greatly 
expanded the capabilities of flight systems which may be 
commanded to a vast number of modes and configurations. 
Automated scheduling systems on the ground are needed to 
support the automated flight systems and keep track of 
operation time lines which contain numerous constraint and 


activity relationships. Manual scheduling is becoming 
impractical. 

2.2 The Need for Flexibility 

Presently, instrument and spacecraft activities are conducted 
according to an operations time line developed ahead of time. 
Users want a more flexible approach that allows real-time 
user interactions with instruments. They want the 
capability to select and perform different activities based on 
the results of real-time telemetry without going through a 
lengthy rescheduling process. Scientists often wish to re- 
plan operations to react to a "target of opportunity” (an 
interesting phenomenon such as a significant sun flare, 
volcano, or hurricane). Rapid, safe rescheduling may be 
carried out more quickly using automated systems instead of 
manual methods. 

2.3 The Need for Safety 

Evaluating the impact of schedule changes is difficult. 
Automated scheduling systems provide increased flexibility 
to manage schedule changes while ensuring health and safety 
of space systems. Automated systems perform constraint 
checking and produce various reports such as impact 
evaluation, schedule statistics, and history logs in order to 
minimize problems introduced by schedule changes. 

2.4 Distributed Scheduling Hierarchy 

Automated scheduling systems are needed to support remote 
science users. Instead of depending on a centralized 
operations control center to operate their instruments, 
science users may directly control the flight instruments 
from a university or other home institution. The planning 
and scheduling capability is no longer centralized in one 
place; instead, the planning and scheduling capability is 
distributed between the operations control center and the user 
sites. Figure 1 and Figure 2 show examples of distributed 
planning and scheduling architectures. 

The system architecture is hierarchical because the 
operations control center must schedule spacc-to-ground 
communications support with the Network Control Center 
(NCC). Planning and scheduling systems exist at the NCC, 
the operations control center, and the customer sites. With 
such a complex architecture, automated scheduling becomes 
mandatory. 

Figure 1 illustrates the planning and scheduling 
hierarchy that currently exists. The network level (level 1) 
contains the NCC and the Flight Dynamics Facility (FDF). 
The NCC is the control center that schedules 
communication services for spacecraft that use the Tracking 
and Data Relay Satellite System (TDRSS). The FDF 
provides orbit, attitude, and navigation products used for 
generating mission plans and schedules. At the platform 
level (level 2), spacecraft arc controlled and managed by 
Payload Operations Control Centers (POCC) or Mission 
Operations Control Centers (MOCC). Presently, at the 
payload level (level 3), the Space Shuttle may contain 
Spacclab payloads managed by the Spacelab POCC. 
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Figure 1. Current [Manning and Scheduling Hierarchy 
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Figure 2. Freedom Era Planning and Scheduling Hierarchy 
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The Space Station Freedom environment is an example 
of a complex, distributed, hierarchical planning and 
scheduling network. For the Freedom era, the planning and 
scheduling process will be more automated and distributed in 
a hierarchy containing additional levels and elements at each 
level. 

Figure 2 illustrates the planning and scheduling 
hierarchy for the Freedom era. With additional levels and 
elements, the Freedom era hierarchy is more complex than 
the current hierarchy. The network level (level 1) is similar 
to the current configuration. The platform level (level 2) 
includes the Earth Observing System Operations Center 
(EOC), the Space Station Control Center (SSCC), and 
POCCs for various spacecraft. At the payload level (level 
3), the Payload Operations Integration Center (POIC) at 
Marshall Space Flight Center (MSFC) coordinates activities 
among the international partners (i.e., Japan and the 
European Space Agency (ESA)] and many Instrument 
Control Centers (ICC) for use of the manned base resources. 
The customer level (level 4) includes the principal 
investigators and the ICCs for the instruments. The ICCs 
may support guest investigators and co-investigators who 
use remote user workstations or Instrument Support 
Terminals (1ST) (level 5) to communicate with an ICC. 

3 The Mission Planning Process 

Figure 3 shows a mission planning process. Strategic 
mission goals arc developed at the beginning of a mission. 
During routine operations, a repetitive planning process 
occurs, typically on a weekly cycle. Investigators and 
coinvestigators generate plans for instrument operations. 
Specific resource availability profiles may not be known due 
to security rules or the commercial proprietary nature of 
certain payloads. 

While investigators arc generating instrument plans, 
spacecraft operations personnel are generating plans for 
maintaining the health and safety of the satellite. These 
plans include operations such as tape recorder dumps, 
command loads, and orbit adjustments. 

Typically a week or two prior to schedule execution, 
plans from the investigators arc integrated with spacecraft 
operations plans, and then schedules are produced. Schedules 
arc analyzed by scheduling personnel to verify that mission 
goals arc being met. If the schedule docs not adequately meet 
the mission goals, it can potentially be improved by using 
the flexibilities specified in the plans (relaxing resource 
requirements or scheduling alternative activities, for 
example). In distributed environments, scheduling personnel 
may request additional resources from other scheduling sites. 
After the schedules are produced, they are sent to the 
investigators. If schedules arc not satisfactory, investigators 
may submit altered plans. 

4 The FERN Language 

In an automated scheduling system, users need to express 
plans for operations in a format that computers can interpret. 


In general, defining requirements is not simple, whether the 
requirements describe software functionality, hardware 
capability, or as in our application, user instrument 
operations plans and resource requirements that support 
science experiments and flight operations. User resource 
requirements may be complex because user activities are 
diverse, flexible, and changeable. Their activities may be 
related to constraints, orbital events, and other activities. A 
belter mechanism is needed to represent this information. 


Mission Goals 



Figure 3. The Mission Planning Process 


Since people use languages to communicate, we 
propose that user plans be represented in a language format 
that computers can process. A language format is needed to 
express the flexibilities and alternatives contained in the 
instrument plans. This method is more expressive than 
using data structures such as arrays, records, and tables. We 
use a language format called FERN (Flexible Envelope 
Request Notation). 

FERN has proven to be a general scheduling language. 
It has been used to represent Solar Mesosphere Explorer 
(SME) requests. Upper Atmosphere Research Satellite 
(UARS) requests, and NCC requests. 

In many scheduling environments currently in 
operation, conflicts are often resolved manually. Sometimes 
users meet to resolve conflicts; however, with increased 
security restrictions due to DOD and commercial payloads, 
this form of conflict resolution might no longer be 
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permitted. FERN provides the flexibility that allows an 
automated scheduling system and project operations 
personnel to resolve conflicts without violating security 
restrictions and rules. 

FERN supports expressing scheduling requirements at 
different levels of abstraction. Detailed resource 
requirements are specified at the lowest level in steps. 
Resource usage within a given step is constant over the 
duration of the step while the duration is often variable. 
Steps can be grouped together into activities. In an 
operational environment, steps would be defined at the 
beginning of a mission and then grouped into meaningful 
activities. Future planning would be done using mnemonic 
activity names without the need to recalculate detailed step 
requirements. A pattern of repetition for activities can be 
specified in a generic request. A generic request can 
succinctly represent a plan for recurring operations. Each 
generic request is assigned a priority by the user, which 
indicates its importance relative to other requests by the 
same user. Temporal constraints can be specified between 
steps or between activities. Figure 4 shows the organization 
of information within generic requests, activities, and steps. 



Figure 4. Information Contained in Steps, 
Activities, and Generic Requests 


The following sections describe in more detail some of 
the specific features of FERN. For each requirement in an 
activity (a resource requirement or a temporal constraint), the 
user may specify a relaxation level ranking from 1 to 10. If 
a schedule is generated that is not consistent with mission 
goals, scheduling personnel may successively relax 
requirements as specified to attempt to improve the schedule. 
Requirements with a ranking of 1 are relaxed first. If no 


relaxation level is specified, the requirement cannot be 
relaxed. 

4.1 Resource Flexibilities 

FERN allows resource amounts to be specified at different 
relaxation levels. For example, a power requirement can be 
specified with two relaxation levels as follows: 

POWER (300 watts 

AND 250 watts AT RELAXATION 2 
AND 150 watts AT RELAXATION 6) 

In this example, if 300 watts of power is not available, the 
scheduling system tries to schedule the request at 250 watts 
and then 150 watts. Requirements with relaxation levels 3, 
4, and 5 are relaxed before the power requirement is relaxed 
from 250 watts to 150 watts. 

With no specified relaxation, the example becomes: 

POWER 300 watts. 

4.2 Temporal Expressions 

We use the term "interval" to represent a window in time 
with a specific start and end time and the term "interval set" 
to represent a collection of nonoverlapping intervals. 
Temporal expressions allow users to create new interval sets 
as functions of predefined interval sets and give names to 
them such as "weekday" and "spacecraft night." Users may 
define new interval sets by applying the UNION, 
INTERSECT, MODIFY, and SELECT operators to existing 
interval sets. 

The UNION and INTERSECT operations are set 
operators. For example, given a temporal interval such as 
"Wednesday" representing a particular 24-hour period and an 
interval set such as "afternoon", which contains the time 
period from 1 p.m. to 4 p.m. every afternoon during a week, 
an interval representing "Wednesday afternoon" could be 
defined by intersecting "Wednesday" and "afternoon". 

The MODIFY operation is useful for changing the start 
and end times of an existing interval. For example, to create 
an interval that lasts from 2 p.m. to 3 p.m. using the pre- 
defined interval above, specify: 

MODIFY Wednesday-aftemoon 

WITH START LATER by 1 hour 
WITH END EARLIER by 1 hour 

The SELECT operator allows specific windows 
(intervals) within an interval set to be "selected". For 
example, to "select" the second and fourth afternoons from 
the "afternoon" interval set, specify the following: 

SELECT afternoon (2,4) 

Temporal expressions are an important tool that enables 
users to work with their own terminology. 
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4.3 Temporal Constraints 

Once a temporal interval such as "Wednesday-aftemoon" is 
defined it can be used within a temporal constraint. For 
instance: 

activity x DURING wednesday-aftemoon. 

FERN contains a general temporal constraint facility for 
expressing indefinite interval relations and the thirteen 
simple interval relations as described in [Vilian and Kautz, 
1986]. Temporal relationships can be specified between two 
activities or steps. One form of a constraint construct is: 

Request x 
[STARTS I ENDS] 

[MORE THAN I LESS THAN I EXACTLY] 

<duration> 

(BEFORE I AFTER] 

[<activity>l <step>]. 

For example. 

Request X starts more than 5 minutes 
before Request Y. 

Simple interval relations such as ’ before” and "after” arc 
expressed in a similiar English-like syntax. 

4.4 Alternative Activities 

Alternative requests allow users to request an entirely 
different activity if the resource scheduling algorithm cannot 
accommodate the initial request. Users want to propose 
alternative experiments if their initial plans cannot be 
supported. 

4.5 A Generic Request Example 

To illustrate the hierarchy of the generic request capability, a 
sample set of FERN definitions is shown below. Upper 
Atmospheric Research Satellite (UARS) contains 10 
scientific instruments. One of these instruments is the 
Improved Stratospheric and Mesospheric Sounder (ISAMS) 
which has a 100 percent duly cycle viewing the Earth's 
atmosphere limb. There are separate instrument modes for 
spacecraft day and night. This example only uses some of 
the expressive capabilities of the language, but it shows the 
ability of generic requests to generate many schedule 
activities over an indefinite period of time: 

Generic ISAMS_NORMAL_GEN is 
1 ACTIVITY PER UARS_Orbit 
SCHEDULE 
ISAMS_Normai_Act 
END GENERIC 

This example of a generic request definition is 
straightforward. One occurrence of the activity 
ISAMS_NormaI_Act is to be scheduled every UARS orbit. 
The activity may turn out to be simple or complex. The 
activity definition is shown below. 


ACTIVITY ISAMS_Normal_Act is 
STEP 

ISAMS_Daytime_View_Step 

FOR AS LONG AS POSSIBLE, 

IS AMS_Nighttime_V iew_S tep 

FOR AS LONG AS POSSIBLE 
END ACTIVITY 

This example shows that the activity is made of two 
parts (steps). The first step occurs when the spacecraft is in 
daylight, and the second step occurs during spacecraft night. 
The activity definition includes the step durations. A 
duration of "for as long as possible" needs a constraining 
time interval. In this case, the constraint is indicated in the 
step definition: 

STEP ISAMS_Daytimc_Vicw_Step is 
RESOURCES 

ISAMS, 

UARS_Power 14 watts 
CONSTRAINT 

Occurs Entirely During UARS_Daylime 
END STEP 


STEP ISAMS_Nightlime_View_Step is 
RESOURCES 

ISAMS, 

UARS_Powcr 14 watts 
CONSTRAINT 

Occurs Entirely During UARS_Nightlime 

END STEP 

Steps contain the resource allocations that support the 
activity. In addition, steps may have constraints that restrict 
time periods when they can be scheduled. The 
ISAMS_Daytime_View_Step can only occur during the 
time period defined as U ARS_Daytime. 
ISAMS_Nighttime_View_Step can only occur during 
UARS_Nighuime. These constraints restrict the actual 
starting and ending times for the steps. If other requested 
resources such as UARS_Power are available during the 
appropriate time periods, the steps are scheduled for the 
entire duration of the time period UARS_Daytimc and/or 
UARS_Nighttime. 

Note that some additional definitions must exist in order 
to process the above FERN requests. Resource availabilities 
for ISAMS and UARS_Power must be defined. Time 
periods for UARS^Orbit, UARS_Daytime, and 
UARS_Nighttime must also be defined. Since the ISAMS 
often performs the same science information gathering 
experiments, these requests can be used repeatedly as needed. 

5 The Request-Oriented Scheduling 
Engine (ROSE) 

ROSE is currently under development as a scheduling tool 
to demonstrate automated scheduling and distributed 
scheduling concepts. The current major capabilities of 
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ROSE are as follows: (1) to receive scheduling messages 
via a file transfer protocol from any scheduler or user located 
on the host network and respond with appropriate scheduling 
messages, (2) to create an initial schedule from user requests, 
and (3) to reschedule (as needed) to satisfy mission goals. 

ROSE was originally implemented on a Texas Instruments 
Explorer and has been ported to the Symbolics 36xx 
environment under Symbolics OS Release 6.1 and Genera 7. 
The system is currently being ported to Ada in a VMS 5.1 
environment using X-windows. Since we anticipate a port 
to a UNIX Sun/3 environment we are avoiding using any 
features that would make this port difficult, such as VMS 
system services, implementation-dependent language 
features, and implementation-dependent X tool kits. 

5.1 Communications Capabilities 

ROSE supports interscheduler communication through the 
transmission of resource requests and schedules. Users 
transmit requests expressed in the FERN language to ROSE. 
The user receives two responses from ROSE. The first is an 
acknowledgement message that confirms receipt of the 
message. This message indicates whether errors were 
detected by the FERN parser. When all requests are received, 
a schedule is created. The second response ROSE sends is 
schedule messages indicating the name of scheduled requests, 
the time assigned to the request, and the resource levels 
dedicated to the request. Users receive a schedule message 
for each request sent to ROSE, but are not informed of the 
disposition of requests from other users. 

5.2 Scheduling Capabilities 

The ROSE system creates an initial schedule from a set of 
requests, resources, and interactively-specified scheduling 
heuristics. ROSE currently schedules activities at the rate of 
approximately 900 activities per hour on a 1 MIP VAX 
workstation for schedules with 1000 - 2000 requests. The 
ROSE operator chooses a selection heuristic and a placement 
heuristic from predefined menus. The selection heuristic 
evaluates each activity and determines which activity should 
be scheduled next based on priorities, resource consumption, 
and an estimation of the restrictiveness of an activity’s 
temporal constraints. The placement heuristic uses activity 
preferences and information about the existing schedule to 
determine the placement of the activity. The ROSE operator 
can create many different alternative schedules by selecting 
different combinations of selection and placement heuristics. 
Alternative schedules can be compared and evaluated with 
respect to mission goals. ROSE always creates conflict-free 
schedules. Manual scheduling is also supported through the 
graphical interface. 

5.3 Rescheduling Capabilities 

In a resource constrained environment, resource conflicts 
will occur, and rescheduling will usually be a necessary step 
after the initial schedule is created. A simple approach for 
scheduling is to resolve resource conflicts by choosing the 
higher priority activity. In a network of ROSE schedulers, 
each allowing flexible requests, there are several options: 


• Overbook the resource. In our distributed scheduling 
environment, overbooking is a viable conflict resolution 
scheme since additional resources can potentially be acquired 
from another scheduler. 

• Relax this activity . A minor adjustment to the 
scheduling requirements of the request might make it 
possible to schedule it. 

• Relax other activities. Higher priority activities 
might have their requirements relaxed in order to 
accommodate lower priority activities. 

• Acquire additional resources. In a network of 
schedulers, it might be desirable to request and obtain 
resources from another scheduler. 

• Manually add the activity. ROSE provides operator 
displays and tools that support the interactive rescheduling 
of existing activities. 

• Use the automated Schedule Enhancement Technique. 
ROSE provides an automated heuristic search capability 
similar to a best-first seaieh. This technique has proven 
useful in enhancing existing schedules. The search proceeds 
by looking for times on the schedule when an activity can 
almost be scheduled. The algorithm then finds those 
activities that need to be deleted to make it possible to 
schedule the activity, and then reschedules the deleted 
activities. This technique is described in more detail in 
(Odubiyi and Zoch, 1989], 

• Choose the higher priority activity . As a last resort, 
some activities are not scheduled. 

• Use any combination of the above capabilities-- An 
operator can mix and combine these techniques as needed to 
improve the current schedule. 

An operator may reschedule activities to improve a 
schedule, to cope with equipment failures, or to 
accommodate changes in plans. The operator is faced with 
an overwhelming amount of information. An interactive 
interface must effectively organize, filter, and display this 
information at the appropriate level of detail to aid an 
operator in making informed scheduling decisions. ROSE 
aids an operator in analyzing and comparing existing 
schedules and in making modifications to improve a 
schedule, respond to changes in resource profiles (equipment 
failures), or respond to new user requests. These features 
have proven to be a valuable aid in assessing the situation 
and modifying existing schedules. 

5.4 ROSE User Interface 

Figure 5 shows the ROSE interface. The three main 
windows are the Distributed Scheduling Network Window, 
the Real-Time Message Monitoring Window, and the 
Timeline of Scheduled Requests Window. 
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Figure 5. ROSE Interface with Sample Schedule and Resource Plots 


The Distributed Scheduling Network Window displays 
the scheduling network and the message traffic within the 
network. Each rectangle represents either a NASA 
scheduling facility such as a Payload Operations Control 
('enter (POCC) or a user Instrument Control Center (ICC). 
Figure 5 shows a simplified scheduling network for Space 
Station Freedom. The Platform Management System 
(PMS) makes block allocations of resources to scheduling 
centers P01 and P02. Scheduling requests are sent from the 
instrument Control Centers (101, 102 and 103) to scheduling 
facilities P01 and P02 where schedules are created. Users at 
101, 102 and 103 are then sent scheduling messages that tell 
them where their requests were scheduled and the amount of 
resources that were allocated. 

The middle portion of the screen is the Real-Time 
Message Monitoring Window. This window displays the 
names of scheduling messages received by this scheduler 
from other schedulers in the network. The user can click on 
these message names to view the details of these messages. 

The lower portion of the screen displays the Timeline of 
Scheduled Requests Window. Schedules are currently one 


week in duration. Each time line shows the requests 
scheduled for a particular user instrument. Multiple 
schedules may be created using different scheduling 
heuristics. Once created, an operator can rearrange these 
time lines so that the different schedules can be compared. 
The operator can also perform standard window 
manipulations such as panning and zooming on any part of 
the time line. The Timeline of Scheduled Requests 
Window, in conjunction with the Unscheduled Request 
Window, provides an object-oriented graphics interface to all 
requests. Every request can be viewed, edited, relaxed, 
scheduled, or unscheduled. 

The Timeline of Scheduled Requests Window is also 
used to display resource plots. Resource profiles can be 
obtained for original resource amounts, remaining resource 
amounts, and resource amounts used by a particular ICC. 

During the scheduling process, a ROSE user can set an 
overbooking limit for each resource. This option is useful 
for investigating the effects of having additional resources. 
The scheduler will treat these extra amounts of resources as 
if they were actually present. As shown in Figure 5, ROSE 
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can display a time line showing where over booked amounts 
are actually utilized. Clicking the mouse on a rectangle on 
this time line generates a display showing which resources 
are overbooked at that time. 

Figure 6 shows the ROSE interface displaying the 
results of a draw available start times operation. This 
display gives the operator a complete understanding of why a 
request could not be scheduled. A time line is displayed for 
each resource requirement or temporal constraint in the 
request. The dark areas on the lime line show where the 
particular requirement is satisfied. The top time line, 
labeled INTERSECTION, displays the intersection of all the 
other time lines. It shows the places where the request can 
be scheduled. As shown in Figure 6, the draw available start 
limes display contains a time line for the following: 

• Every resource or environmental constraint used by 
the request (POWER, COM-LINK, TAPE-RECORDER, 
VIBRATION, and N02-SPEC). The dark areas show places 
on the lime line where sufficient resources arc available to 
meet the needs of this request. 


• Each temporal constraint (labeled 1 and 2). The dark 
areas show places where the temporal constraint is satisfied. 

• The DIRECTION constraint (labeled DIRECT). This 
is a special type of temporal constraint. 

Two summary time lines arc also shown, labeled 
DYNAMIC and TEMPORAL. The DYNAMIC time line 
shows where a request can be scheduled based on its required 
positioning with respect to other requests. The 
TEMPORAL lime line displays the intersection of all 
temporal constraints and the special DIRECTION constraint 
for the request. 

The draw available start times display identifies the 
schedule conflict areas. For example, the N-PROBE-3 
request has a DIRECTION constraint that is restricting the 
scheduling of this request to a short period early in the 
schedule. The N02-spcctromctcr instrument is busy during 
the early part of the week, making it impossible to schedule 
die request. Other resources such as POWER and TAPE- 
RECORDERS arc abundant. 
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Figure 6. ROSE Interface with Display of Available Start Times for Request N-PROBE-3 
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6 Conclusion 

Wc have addressed a difficult aspect of mission planning and 
scheduling-representing the available flexibilities in plans 
to aid in the automation of the scheduling process and reduce 
replanning. The increased automation is necessary to 
support increasingly complex future NASA missions. 

The FERN planning language is designed to be robust, 
readable, flexible, and object-oriented. FERN supports a 
variety of user resource requirements and constraints. It 
supports alternative plans and repetitive activities that are 
based on temporal expressions (user-defined time periods) 
rather than specific start times. The language contains 
hierarchical constructs that support data abstraction and 
reusable data objects. 
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